Serializable objects and a database thereof

ABSTRACT

A technique to communicate data between a management layer and an interface layer of a network device having traffic modules and compute modules includes using a converter to convert a serializable object between file formats. The management layer is executed on at least one of the compute modules and the interface layer is executed on the one of the compute modules. Data is communicated between the interface layer and the management layer via invoking the converter to convert the data from a first format used in the interface layer to a serializable object in the management layer.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is a Divisional of U.S. patent application Ser.No. 11/586,769, filed on Oct. 25, 2006.

TECHNICAL FIELD

This disclosure relates generally to software, and in particular but notexclusively, relates to databases.

BACKGROUND INFORMATION

FIG. 1 illustrates a conventional database system 100 including adatabase 105 and a database client 110. As illustrated, database 105stores separate internal keys indexed to each record or data buffer. Itis noteworthy that the internal keys are not apart of the record or thedata buffer of the record, and do not contain useful data, other thanfor the purposes of organization and retrieval. To retrieve a particularrecord, database client 110 provides a key 115 to database 105, which inturn searches on it internal keys. If a match is found, then database105 will return a record 120 indexed to the internal key that matchedkey 115 provided. To write data buffers or records into database 105,database client 110 may reference a database (“DB”) schema 125, whichincludes a description of the internal structure or directory system ofdatabase 105. In short, schema 125 provides database client 110 with theknowledge necessary to access and utilize database 105.

Since database 105 merely indexes data buffers or records to internalkeys, the knowledge and complexity required to run higher level querieson database 105 is pushed onto application developers of database client110. Furthermore, since the internal keys themselves are not part of theuseful data stored by database client 110, but rather independentlygenerated values used simply for retrieving records or data buffers, theinternal keys consume additional memory resources within database 105.

In an alternative conventional database system, database 105 itself maycontain knowledge of the internal representation of the data buffers orrecords it stores to perform it own complex queries and indexing. Thisalternative embodiment pushes the complexities of indexing and queriesonto the database developer; however, does so at the expense ofperformance by adding a layer of abstraction between the records storedand the database clients accessing the records.

BRIEF DESCRIPTION OF THE DRAWINGS

Non-limiting and non-exhaustive embodiments of the invention aredescribed with reference to the following figures, wherein likereference numerals refer to like parts throughout the various viewsunless otherwise specified.

FIG. 1 (PRIOR ART) illustrates a conventional database system.

FIG. 2 is a diagram illustrating a mesh interconnect between traffic andcompute modules of a network service element, in accordance with anembodiment of the invention.

FIG. 3A is a block diagram illustrating a layered software stackexecuting on a module of a network service element, in accordance withan embodiment of the invention.

FIG. 3B is a table illustrating which layers of a layered software stackexecute on an OAMP module, a compute module, or a traffic module of anetwork service element, in accordance with an embodiment of theinvention.

FIG. 4A is a block diagram illustrating how converters can convert aserializable object into a variety of different data formats, inaccordance with an embodiment of the invention.

FIG. 4B is a block diagram illustrating how two converters may be linkedin series, in accordance with an embodiment of the invention.

FIG. 5A illustrates a serializable object, in accordance with anembodiment of the invention.

FIG. 5B is a table illustrating the basic types of a serializableobject, in accordance with an embodiment of the invention.

FIG. 5C illustrates a converter including read and write methods foreach basic type of a serializable object, in accordance with anembodiment of the invention.

FIG. 6A is a flow chart illustrating a process for writing from aserializable object, in accordance with an embodiment of the invention.

FIG. 6B is a block diagram illustrating how a serializable object may beconverted to other file formats through a converter, in accordance withan embodiment of the invention.

FIG. 6C is a flow chart illustrating a process for reading into aserializable object, in accordance with an embodiment of the invention.

FIG. 7 is a block diagram illustrating a technique for reading aserializable object from a database, in accordance with an embodiment ofthe invention.

FIG. 8 is a flow chart illustrating a process for reading a serializableobject from a database, in accordance with an embodiment of theinvention.

FIG. 9 is a block diagram illustrating a technique for writing aserializable object into a database, in accordance with an embodiment ofthe invention.

FIG. 10 is a flow chart illustrating a process for writing aserializable object into a database, in accordance with an embodiment ofthe invention.

FIG. 11 is a block diagram illustrating interconnections between trafficmodules and compute modules of a network service node, in accordancewith an embodiment of the invention.

FIG. 12 is a block diagram illustrating a compute module, in accordancewith an embodiment of the invention.

FIG. 13 is a block diagram illustrating a traffic module, in accordancewith an embodiment of the invention.

DETAILED DESCRIPTION

Embodiments of a system and method for serializable objects and aserializable objects database are described herein. In the followingdescription numerous specific details are set forth to provide athorough understanding of the embodiments. One skilled in the relevantart will recognize, however, that the techniques described herein can bepracticed without one or more of the specific details, or with othermethods, components, materials, etc. In other instances, well-knownstructures, materials, or operations are not shown or described indetail to avoid obscuring certain aspects.

Reference throughout this specification to “one embodiment” or “anembodiment” means that a particular feature, structure, orcharacteristic described in connection with the embodiment is includedin at least one embodiment of the present invention. Thus, theappearances of the phrases “in one embodiment” or “in an embodiment” invarious places throughout this specification are not necessarily allreferring to the same embodiment. Furthermore, the particular features,structures, or characteristics may be combined in any suitable manner inone or more embodiments.

FIG. 2 is a schematic diagram illustrating a mesh interconnect betweentraffic and compute modules of a network service element 200, inaccordance with an embodiment of the invention. The illustratedembodiment of network services element 200 includes a mesh interconnect205 coupling traffic modules 210 and compute modules 215. Each of thetraffic and compute modules 210 and 215 provide the processing power toimplement packet processing, routing, and other functionality. In oneembodiment, network service element 200 is a service node intended to beconnected between two or more networks (e.g., between core networksproviding services and aggregation networks providing access to clientsconsuming the services), which may implement additional functionalitysuch as traffic shaping, guarantee quality of service (“QoS”), admissionprotocols, or otherwise.

In the illustrated embodiment, network service element 200 isimplemented using an Advanced Telecommunication and ComputingArchitecture (“ATCA”) chassis. Mesh interconnect 205 may providecross-connectivity between traffic and compute modules 210 and 215 withthe ATCA backplane. In the exemplary configuration shown in FIG. 2, theATCA chassis is fully populated with 14 ATCA blades (i.e., traffic andcompute modules 210 and 215), with each blade installed in a respectivechassis slot—in an actual implementation, the chassis may be populatedwith less blades or may include other types of blades in addition tocompute and traffic blades. The illustrated configuration includes fourcompute modules 215 ₁₋₄, and 10 traffic modules 210 ₁₋₁₀, with one ofthe compute modules being provisioned to provide operations,administration, maintenance and provisioning functionality (“OAMP”)functions. As depicted by interconnection mesh 205, each module iscommunicatively-coupled with every other module under the control offabric switching operations performed by each module's fabric switch. Inone embodiment, mesh interconnect 205 provides a 10 Gbps connectionbetween each pair of modules, with an aggregate bandwidth of 280 Gbps.

In the illustrated embodiments, network service element 200 isimplemented using a distributed architecture, wherein various processorand memory resources are distributed across multiple modules. To scale asystem, one simply adds another module (e.g., blade). The system isfurther enabled to dynamically allocate processor tasks, and toautomatically perform fail-over operations in response to a modulefailure or the like. Furthermore, under an ATCA implementation, modulesmay be hot-swapped without taking the system down, thus supportingdynamic scaling.

FIG. 3A is a block diagram illustrating a layered software stack 300executing on a module of network service element 200, in accordance withan embodiment of the invention. The illustrated embodiment of layeredsoftware stack 300 includes a hardware abstraction layer (“HAL”) 305, aruntime layer 310, a management layer 315, and an interface layer 320.

HAL 305 abstracts the underlying hardware resources to the softwarelayers above and may include various device drivers, a kernel, softwarebuffers, or the like. Runtime layer 310 is used to maintain dynamicstate information for the modules of network service node 200, which maybe in a state of flux during operation. For example, routing demons mayexecute in runtime layer 310 to setup and tear down route changes, toreceive and process open shortest path first (“OSPF”) protocol packets,or service other dynamic change requests coming up from HAL 305.

Management layer 315 services application programming interface (“API”)calls from interface layer 320 and translates the calls into data,typically to be stored into a provisioning database 325 or occasionallyinto a runtime database 330. The APIs are published into interface layer320 via a management layer API (“MLAPI”), which may provide a variety ofAPIs for accessing the databases. For example, the MLAPI may publishfive APIs into interface layer 320 including a set API, a get API, a getmultiple API, a create API, and a remove API. Management layer 315typically facilities the provisioning of static attributes assigned tothe modules of network service node 200. For example, static attributesmay include port assignments, the existence (or lack thereof) of amodule in a slot, power settings, a registry of applications executingon each module, and the like.

Finally, interface layer 320 proves an access layer to enable a user(e.g., network administrator or other Information Technology (“IT”)technician) to interface with network service element 200 and the lowerlayers of layered software stack 300. For example, the user may invokeany of the APIs published by the MLAPI using a command line interface(“CLI”) to get (e.g., retrieve) one or more records stored inprovisioning database 325 or runtime database 330, create a new record,remove (e.g., delete) an existing record therefrom, or set an attributeof an object existing in lower layers of layered software stack 300. Inother cases, the interface layer 320 may enable the user to pushuser/data files (e.g., extensible markup language (“XML”) files, etc.)down to the lower layers through one or more converters.

As mentioned, interface layer 320 enables a user to push in data files340 from external sources. Data files 340 may be XML files, C objects,C++ objects, C# objects, Java objects, or otherwise. As a data file 340is pushed down to management layer 315, layered software stack 300 mayconvert data file 340 into a serializable object 345. A serializableobject (“SO”) is a software object that lends itself well toserialization and which is typically a complex of linked memorystructures. As SO 345 is pushed further down to runtime layer 310, SO345 may be converted into a flat structure 350. Flat structure 350typically is a fixed length contiguous memory structure which may bequickly and easy manipulated in memory and therefore well suited for thehigh speed, dynamic environment of runtime layer 310.

Provisioning database 325 may be used to store provisioning data forsetting static or semi-static attributes of network service element 200,while runtime database 330 may be used to store runtime data arriving ondatapaths rising up from HAL 305. In one embodiment, provisioningdatabase 325 may convert SO 345 into variable length, compressed, flatmemory structures, prior to storing SO 345, while runtime database 330may simply store flat structure 350 as a fixed length, uncompressed,flat structure. Since runtime layer 310 manages high speed, dynamicallychanging events, it is reasonable to tradeoff memory consumption (e.g.,fixed length, uncompress structures) in exchange for low latency, highspeed access to runtime database 330. In contrast, management layer 315typically manages static or semi-static attributes, thereforecompressed, variable length structures are advantages, even at theexpense of incurring some processing overhead related to accessingvariable length structures.

FIG. 3B is a table illustrating how software components of layeredsoftware stack 300 may be distributed across multiple modules of networkservice element 200, in accordance with an embodiment of the invention.As illustrated, an OAMP module (which may be one of compute modules 215selected to implement OAMP functionality) includes runtime layer 310,management layer 315, and interface layer 320. In contrast, ordinarycompute modules 215 and traffic modules 210 may only execute runtimelayer 310.

FIG. 4A is a block diagram illustrating how converters can convertserializable objects into a variety of different data formats, inaccordance with an embodiment of the invention. As illustrated, an SO400 may be written to or retrieved from a database 405 via a database(“DB”) converter (“CV”) 410, may read in commands from a CLI 415 via aCLI CV 420, may write to or read from a network connection 425 via anetwork (“NET”) CV 430, may write to or read from a variety of fileformats (e.g., generic file 435, C++ code 440, C# code 445, XML file450, etc.) via a variety of corresponding converts (e.g., generic fileCV 455, C++ CV 460, C# CV 465, XML CV 470, etc.), output text to adisplay 475 via a print CV 480, or the like.

SO 400 may operate as a sort of intermediary between the various fileformats and provides a sort of common currency within a processingsystem between various entities, which otherwise communicate in adifferent language or format. SO 400 is amenable to serialization andconversion between some or all of the various file formats listed above,as well as others. Generic file CV 455 is included in FIG. 4A toillustrate that converters may be provided to convert SO 400 to a numberof different file types beyond those illustrated in FIG. 4A. Forexample, file 435 may represent a Java file or any other file type orformat. In one embodiment, the converters are software modules that aregenerated and linked to endpoints (e.g., DB 405, CLI 415, network 425,file 435, C++ code 440, C# code 445, XML file 450, display 475, etc.)and may be invoked by SO 400 to read from or write to the selectedendpoint.

FIG. 4B is a block diagram illustrating how two or more converters maybe linked in series, in accordance with an embodiment of the invention.In one embodiment, multiple CVs may be linked together or “daisychained” to enable multiple CVs to act upon data communicated betweentwo endpoints without generating an intermediary serializable object.For example, FIG. 4B illustrates an encryption CV 490 and a file CV 492coupled together between an SO 494 and an encrypted file 496. In oneembodiment, encryption CV 490 and file CV 492 are linked to encryptedfile 496. In this embodiment, SO 494 may write to or read from encryptedfile 496 simply by invoking encryption CV 490. To write to encryptedfile 496, SO 494 may output data to encryption CV 490, which encryptsthe data. Encryption CV 490 then passes the encrypted data to file CV492, which converts/formats the encrypted data into encrypted file 496.To read from encrypted file 496, SO 494 may invoke read methods withinencryption CV 490, which in turn may invoke read methods within file CV492, which in turn retrieve the encrypted file data from encrypted file496. As the data is passed back to SO 494, it is converted/formatted byfile CV 492 and decrypted by CV 490. It should be appreciated that inother embodiments, the order of encryption CV 490 and file CV 492 may beswapped.

In one embodiment, converters may be used to perform software upgradesof serializable objects. The converters could be inserted in theexecution runtime to perform “in service software upgrades” to translatethe serializable objects between version v1 to version v2. Updating anSO may include removing a field with the SO, rearranging the order ofone or more fields, adding new fields, or changing the type of a field(i.e., translating the field from one basic type to another). Asillustrated in FIG. 4B, upgrades from version v1 to a version v4 may beimplemented by linking or daisy chaining converters in series. In thismanner, each software release need only create a converter forconverting from the previous release.

FIG. 5A illustrates an SO 500, in accordance with an embodiment of theinvention. SO 500 represents one possible embodiment of SO 400 or 494illustrated in FIGS. 4A and 4B. The illustrated embodiment of SO 500includes a read method, a write method, a to_struct method, afrom_struct method, and a plurality of fields 505 (e.g., field 1, field2, field 3, field 4, etc.). Each field 505 includes a declared variable510 (e.g., VAR_A, VAR_B, VAR_C, VAR_D, etc.), which may or may not beassigned a field value 515 (e.g., VALUE_A, VALUE_B, VALUE_C, etc.).Assigning a field value 515 to a variable 510 may interchangeably bereferred to herein as “setting a field” or “setting a variable.”

One or more fields 505 may be marked with an index 520. Indexes 520 aresubstitute identifiers that may be used to reference the correspondingmarked field 505. Indexes 520 enable SO 500 to write out subsets of itsfields 505, through a converter, into any other form. In one embodiment,indexes 520 may either represent a primary index or a secondary index. Aprimary index 520 is an index 520 which may be used to uniquely identifySO 500 from all other SO's. Accordingly, the primary index marks a field505 having a unique field value 515. In one embodiment, an index valueof ‘1’ is reserved for the primary index. The same index value may beused to mark multiple fields 505, as illustrated by index value ‘2’marking fields 2 and 3. By invoking index value ‘2’, the field values515 (e.g., VALUE_A and VALUE_B) corresponding to the fields 505 markedwith an index 520 having an index value of ‘2’ are referenced.

The to_struct method and the from_struct method may be invoked by SO 500to convert itself into a fixed length, flat, contiguous memory structureor generate itself from a fixed length, flat, contiguous memorystructure, respectively. These methods may be useful for manipulatingflat contiguous memory structures in runtime layer 310 (see FIG. 3A),and particularly, for converting an SO in interface layer 320 ormanagement layer 315 into flat structure 350 in runtime layer 310. Theto_struct method enables a user to quickly push an SO down into runtimedatabase 330. The to_struct method pre-allocates memory and defines howto map the complex linked memory structures of SO 500 into fixed length,flat, contiguous memory structures, which are amenable to high speedmanipulation. The from_struct method may be invoked by a blank or emptySO to populate its fields 505 with data from a flat structure.

In one embodiment, fields 505 may include flags (not illustrated) foridentifying each field 505 as “set”, “unset”, or “modified.” When anobject reads in an unset field 505 from source object, the reader willsimply read in a default value for the unset field, as opposed toreading the unset field 505 from the source object. In contrast, thereader will actually read in field values 515 from a source object forfields 505 marked as “set”. The modified flag may be used to indicatewhether or not a particular field 505 has been changed, whether or notit is set or unset. For example, a field 505 marked as “unset” and“modified” indicates that a user has explicitly unset a field 505, asopposed to a field 505 that was initialized as “unset” with a defaultvalue.

In one embodiment, SO 500 may include a merger function to merger itsfield values 515 with the field values 515 from another SO. In thiscase, if a field 505 is flagged as “modified”, then it field value 515is retained, while fields 505 flagged as unmodified will retain existingvalues. In one embodiment, SO 500 may include a comparison function(e.g., diff_struct), which may be invoked to compare SO 500 againstanother SO. The output of the comparison function may be a bit field foreach field 505, where a ‘1’ represents “is different” and a ‘0’represents “is same.”

FIG. 5B is a table 530 illustrating the basic types of a serializableobject, in accordance with an embodiment of the invention. As discussedabove, SO 500 may include a number of fields 505 having associatedvariables 510. Variables 510 may be declared as having one of the basictypes listed in table 530. It is noteworthy that basic type number(“BT#”) 11, labeled as “complex”, is a hierarchical or linked structurebasic type that can be defined as a combination of other basic types,including a complex basic type. In this manner, serializable objects maybe embedded within other serializable objects as a complex basic type.While table 530 lists 11 basic types, it should be appreciated thattable 530 is merely representative and not intended to be a definitiveor exhaustive list. Rather, some embodiments may include more, less, oralternative basic types than those listed in table 530.

FIG. 5C illustrates a converter 540, in accordance with an embodiment ofthe invention. Converter 540 represents one possible embodiment of theconverters illustrated in FIGS. 4A and 4B (e.g., DB CV 405, CLI CV 420,NET CV 430, C++CV 460, file CV 455, C# CV 465, print CV 480, or XML CV470). The illustrated embodiment of converter 540 includes a pluralityof read methods 550 for reading each of the basic types listed in table530 (e.g., read BT(1), read BT(2) . . . , read BT(N)) and a plurality ofwrite methods 555 for writing each of the basic types listed in table530 (e.g., write BT(1), write BT(2) . . . , write BT(N)). Converter 540accepts field values 515 and their corresponding variable names 510 asinputs and converter these inputs to a specific form. Accordingly, SO500 can call converter 540 on each of its fields 505 or a subset of itsfields 505 to convert itself, in whole or in part, to some other form.

Operation of converter 540 to write from or read into SO 500 is nowdescribed with reference to FIGS. 6A, 6B, and 6C. FIG. 6A is a flowchart illustrating a process 605 for writing from SO 500, in accordancewith an embodiment of the invention. In a process block 610, one or morefields within SO 500 are “set” or assigned specific field values 515. Ina process block 520, the write method within SO 500 is invoked, which inturn will invoke converter 540 (process block 620).

Once invoked, converter 540 will execute a corresponding one of itswrite methods on each set field 505 in SO 500. For example, if VAR_A wasdeclared as basic type INT64 (i.e., 64 bit integer), then converter 540will invoke WRITE BT(4), corresponding to INT64 in table 530. Similarly,if VAR_B was declared as basic type BOOLEAN, then converter 540 willinvoke WRITE BT(10), corresponding to basic type BOOLEAN in table 530.Each write method 555 invoked by converter 540 will access thecorresponding field 505, convert the contents of the field based on theconverter type, and write out the converted field to the destinationobject/file (process block 625).

In one embodiment, specific fields 505 of SO 500 may be referenced to bewritten out by specifying corresponding indexes 520. For example, byinvoking a write method, identifying a particular converter, and passingone or more index values to the write method, specified fields 505 maybe written out from SO 500, while skipping others. In one embodiment,the default setting is writing out all fields 505 when a write method isinvoked, without specifying index values. In one embodiment, all fields505 may be written out by passing a default index number, such as ‘0’.

FIG. 6B illustrates how each fields 505 of SO 500 are independentlypassed into the corresponding write methods 555 of converter 540. In oneembodiment, if CV 540 is a database converter (e.g., DB CV 405), thenfields 505 are serialized and flattened into a flat database structure630. In one embodiment, if CV 540 is a C++ converter (e.g., C++ CV 460),then fields 505 are converted into fields of a C++object/file 635. Inone embodiment, if CV 540 is an XML converter (e.g., XML CV 470), thenfields 505 are converted into attributes of an XML object/file 640.

FIG. 6C is a flow chart illustrating a process 650 for reading fieldvalues into SO 500, in accordance with an embodiment of the invention.To commence reading field values 515 into SO 500, the read method of SO500 is invoked (process block 655) and a converter identified (processblock 660). As discussed above, converters (e.g., CV 540) may bepre-generated and linked to a source file or object. Therefore, once theread method is invoked and a specific converter identified, data fromthe source object/file is read into SO 500 through the specifiedconverter (process 655). In one embodiment, the read method of SO 500invokes corresponding read methods 550 within converter 540 to read ineach field value 515. As each read method 550 of converter 540 isinvoked, it converts the basic types from the format of the sourceobject/file to the format of SO 500. In one embodiment, only specifiedfields 505 may be populated with read in values by passing index values520 to the read method of SO 500.

As discussed above, to translate SO 500 from interface layer 320 ormanagement layer 315 to runtime layer 310, SO 500 may be converted intoa flat structure using the to_struct method ( ). There may be somescenarios where it may be desirable to store more than one type of SOinto runtime database 330. This may be achieved using a concept referredas “union”. From interface layer 320 or management layer 315 records maybe passed down to runtime layer 310 that contain multiple types. Forexample,

Class Foo {   Key *key;   Record *data; };The types Key and Record are base classes of a serializable objectlanguage (“SOL”). The class Foo can contain many different types of Keyand many different types of Record, such as,

MyRecord: public Record {   // My special data; }; MyKey: public Key {  //My special data; };.So, there could be MyKey, YourKey, HisKey, MyRecord, YourRecord,HisRecord, or the like. Therefore, the class Foo could be made up of anymixture of these types, since they inherit from Key and Record. This isreferred to as “polymorphism.” In order to translate Foo into runtimedatabase 330, Foo is converted into a flat structure, which then getsstored into runtime database 330. This may be achieved by marking theclass Foo with a special attribute, such as,

class Foo { [SOField(union=MyKey, YourKey, HisKey)]   Key *key;[SOField(union=MyRecord, YourRecord, HisRecord)]   Record *data; };With this special attribute an SOL compiler can automatically generatecode that will result in,

class Foo {  struct_type  {   enum which_t { MYKEY, YOURKEY, HISKEY };  which_key_t isset;   union _u1   {   MyKey::_type mykey;  YourKey::_type yourkey;   HisKey::_type hiskey;   }   enum which_t {MYRECORD, YOURRECORD, HISRECORD };   which_record_t isset1;   union _u2  {   MyRecord::_type myrecord;   YourRecord::_type yourrecord;  HisRecord::_type hisrecord;   }  };  Key *key;  Record *data; };The _type structure represents the flat union for storage into runtimedatabase 330. The SOL compiler may generate serialization code that willmove back and forth from the _type::_u1 and _type::_u2 into the correctkind of objects in the Key *key and Record *data fields. For example, if*key contained a MyKey, then the generated code may perform a to_struct() call from the *key (which is a MyKey) into the field _type::_u1::mykey. Next, the generated code would set the which_key_t field tobe equal to MYKEY. On the way back, the generate code would look at thewhich_key_t field and switch on the type,

Switch (which) {   Key *whichkey;   case MYKEY: Whichkey = new MyKey;Whichkey -> fromstruct (_type::_u1::mykey);   case YOURKEY:   caseHISKEY: } key = whichkey;.In one embodiment, the above functionality may be embedded within SO 500and invoked by calling a to_union ( ) method or a from_union ( ) method.The to_union ( ) and from_union ( ) methods enable moving from a choiceof structures into a union automatically and facilitates transferringobjects from interface layer 320 through management layer 315 and downto runtime layer 310 into runtime database 330.

FIGS. 7 and 8 illustrate a technique for reading a serializable objectfrom a database 705, in accordance with an embodiment of the invention.FIG. 7 is a block diagram illustrating the technique, while FIG. 8illustrates a process 800 for the same. The order in which some or allof the process blocks appear in each process described herein should notbe deemed limiting. Rather, one of ordinary skill in the art having thebenefit of the present disclosure will understand that some of theprocess blocks may be executed in a variety of orders not illustrated.

In a process block 805, an empty SO 710 is created (illustrated in FIG.7 by arrow 1). An empty SO is a serializable object where none of thefields have been set or assigned field values. Empty SO 710 may becreated by instantiating a new SO based on a class definition file 715.In a process block 810, one or more fields of empty SO 710 (e.g., fields505) are set or assigned field values (illustrated in FIG. 7 by arrow 2)to create set SO 715. In the embodiment illustrated in FIG. 7, field 1is set with a field value “VALUE_A.” In a process block 815, a GETcommand is issued on database 705 (illustrated in FIG. 7 by arrow 3) toretrieve data from database 705. In one embodiment, the GET command maybe invoked from interface layer 320 via the MLAPI.

In one embodiment, the GET command is passed set SO 715, a destinationaddress or pointer 720 to a destination object to which database 705should return the data, and one or more index values 725. Thedestination object may be set SO 715 itself, or some other object orfile. Index value(s) 725 passed into the GET command indicates todatabase 705 which fields 505 of all the objects stored in database 705it should inspect and attempt to match against the set fields of set SO715. The set field value (e.g., VALUE_A) operates as the key forsearching database 705 to find any SO stored therein having a fieldmarked with an index value matching index value 725 (e.g., index 1) andhaving a corresponding field value matching field value VALUE_A.Accordingly, a user of database 705 can query database 705 using thedata, itself, rather than using an extraneous or separate key.Furthermore, even though multiple fields of set SO 715 may be set withfield values, by selecting different index values corresponding todifferent fields, a particular record (e.g., serializable object) storedin database 705 can be searched for using a variety of different data asthe key. Fields 505 marked with the primary or secondary indexes providesearch flexibility to the end user to query database 705 based on avariety of different subsets of the data/fields within set SO 715.

For example, database 705 may store phone records that include thefollowing three fields: a name field, a phone number field, and anaddress field. If the name fields are marked with index value 1, thephone number fields are marked with index value 2, and the addressfields are marked with index value 3, then a user who wishes todetermine the phone number associated with a particular name would setthe first field with the name and pass the set SO to the GET command.Since the name field is marked with an index value 1, index value 725would be passed as a ‘1’ into the GET command. Of course, the user couldalso set the address field and/or phone number field, pass the set SO tothe GET command, and retrieve the corresponding name.

Returning to FIG. 8, in a process block 820, the one or more set fieldsmarked with index value(s) 725 is/are converted to flat contiguousmemory structure(s) 730 by database CV 405. As illustrated, serializableobjects that exist outside of database 705 may exist as link memorystructures 735, which are serialized into flat contiguous memorystructures 730 prior to passing into database 705. Although DB CV 405 isillustrated as external to database 705, it should be appreciated thatDB CV 405 may in fact be an internal component to database 705. Oncepassed into database 705 by the GET command, a query is executed todetermine whether a matching record index value/field value pair exists(decision block 825). If such a record is not found, then an empty set,null, or void response is returned to the destination object in aprocess block 830. If such a record is found, then process 800 continuesto a process block 835.

In process block 835, the matching record (or records) is converted froma flat contiguous memory structure 740 into a more complex linked memorystructure 745 by DB CV 405 and returned to the destination object(illustrated as set SO 715 in FIG. 7). Finally, in a process block 840,the data from the matching record is written into the destination objectto populate the empty fields of set SO 715 with field values from thematching record stored in database 705.

FIGS. 9 and 10 illustrate a technique for writing SO 500 into database705, in accordance with an embodiment of the invention. FIG. 9 is ablock diagram illustrating the technique, while FIG. 10 illustrates aprocess 1000 for the same. In a process block 1005, one or more fields505 within SO 500 are set. Once fields 505 are set, the write methodwithin SO 500 may be invoked (process block 1010) and database CV 405identified (process block 1015). Once invoked, database CV 405 convertsthe complex linked memory structures 905 of SO 500 into a flatcontiguous memory structure 910 (process block 1020) and stores flatcontiguous memory structure 910 in database 705 (process block 1025). Inone embodiment, database CV 405 may be internal to database 705, ratherthan external as illustrated. In one embodiment, an SO identifier(“SOID”) is tagged onto flat contiguous memory structure 910 prior tostoring flat contiguous memory structure 910 into database 705 as arecord. The SOID is a unique ID, which may also be referenced whenretrieving a stored record.

In one embodiment, SO 500 may be written into database 705 by invokingthe CREATE command published by the MLAPI into interface layer 320. Inthis embodiment, the CREATE command may be passed SO 500 and one or moreindex values to identify which fields 505 are to be written intodatabase 705. In this manner, a subset of the data or fields 505 withinSO 500 may be written into database 705.

In accordance with architecture aspects of some embodiments, theaforementioned functions may be facilitated by various processing andstorage resources hosted by associated line cards and the like, whichare mounted in a common chassis. As shown in FIG. 11, from a datapathperspective, the hardware architecture of one embodiment of networkservice node 200 can be decomposed into three entities, Traffic Blades(TB) 210, Compute Blades (CB) 215 and the chassis 1104. A TB 210 can befurther reduced to its physical and link layer portions 1106 and 1108,network layer components 1110, and infrastructure components 1112.Similarly, a CB 215 provides Service Layer termination 1113 andinfrastructure components 1114. In one embodiment, a CB can be furtherre-defined to be an OAMP Blade based on its slot index (within chassis1104). OAMP blades are a functional superset of CBs, adding operations,administration, maintenance, and provisioning functionality(collectively referred to as OAMP card function or OAMP CF).

As illustrated in the embodiments herein, chassis 1104 comprises anAdvanced Telecommunication and Computing Architecture (ATCA orAdvancedTCA®) chassis. The ATCA Chassis provides physical connectivitybetween the blades via a passive backplane 1116 including a full-meshinterconnect 1118. It is noted that the ATCA environment depicted hereinis merely illustrative of one modular board environment in which theprinciples and teachings of the embodiments of the invention describedherein may be applied. In general, similar configurations may bedeployed for other standardized and proprietary board environments,including but not limited to blade server environments.

The ATCA 3.0 base specification (approved Dec. 30, 2002), which is beingcarried out by the PCI Industrial Computer Manufacturers Group(“PICMG”), defines the physical and electrical characteristics of anoff-the-shelf, modular chassis based on switch fabric connectionsbetween hot-swappable blades. (As used herein, the terms “board,”“blade,” and “card,” are interchangeable.) This specification definesthe frame (rack) and shelf (chassis) form factors, core backplane fabricconnectivity, power, cooling, management interfaces, and theelectromechanical specification of the ATCA-compliant boards. Theelectromechanical specification is based on the existing IEC60297EuroCard form factor, and enables equipment from different vendors to beincorporated in a modular fashion with guaranteed interoperability. TheATCA 3.0 base specification also defines a power budget of 200 Watts (W)per board, enabling high performance servers with multi-processorarchitectures and multi gigabytes of on-board memory.

In addition to power input to ATCA boards, mating connectors on theboards and backplane are employed for coupling input/output (I/O)signals. Many of the ATCA boards, as well as other modular boards usedfor telecommunications and computer, such as but not limited toCompactPCI, employ very-high speed I/O channels. For example, AdvancedSwitching (“AS”) employs a serial communication channel operating atGigahertz+frequencies. ATCA boards may also provide one or more I/Oports on their front panels, enabling an ATCA board to be coupled toother network resources.

An exemplary architecture 1200 for a compute blade 215 is shown in FIG.12. In one embodiment, a single compute blade (physical) architecture isemployed for both Compute Blades and OAMP CF's. More particularly, underarchitecture 1200, a corresponding blade may be deployed to support bothCompute Blade and OAMP functionality.

Compute Blade 215 employs four multiple processor compute nodes 1202₁₋₄. In general, each of compute nodes 1202 ₁₋₄ functions as multipleprocessor resources, with each processor resource being associated witha logical processor. Accordingly, such processor resources may beimplemented using separate processors, or processor chips employingmultiple processor cores. For example, in the illustrated embodiment ofFIG. 13, each of compute nodes 1202 ₁₋₄ is implemented via an associatedsymmetric multi-core processor. Exemplary multi-core processors that maybe implemented include, but are not limited to Broadcom 1480 and 1280devices. Each of the compute nodes 1202 ₁₋₄ is enabled to communicatewith other compute nodes via an appropriate interface (e.g., bus orserial-based interfaces). For the Broadcom 1480 and 1280 devices, thisinterface comprises a “Hyper Transport” (HT) interface. Other native(standard or proprietary) interfaces between processors may also beemployed.

As further depicted in architecture 1200, each compute nodes 1202 ₁₋₄ isallocated various memory resources, including respective RAM 1204 ₁₋₄.Under various implementations, each of compute nodes 1202 ₁₋₄ may alsobe allocated an external cache 1206 ₁ ₄, or may provide one or morelevels of cache on-chip. In one embodiment, the RAM comprises ECC (ErrorCorrection Code) RAM. In one embodiment, each compute node employs aNUMA (Non-Uniform Memory Access) cache coherency scheme. Other cachecoherency schemes, such as MESI (Modified, Exclusive, Shared,Invalidated), may also be implemented for other embodiments.

Each Compute Blade 215 includes a means for interfacing with ATCA meshinterconnect 1118. In the illustrated embodiment of FIG. 12, this isfacilitated by a Backplane Fabric Switch 1208. Meanwhile, a fieldprogrammable gate array (“FPGA”) 1210 containing appropriate programmedlogic is used as an intermediary component to enable each of computenodes 1202 ₁₋₄ to access backplane fabric switch 1208 using nativeinterfaces for each of the compute nodes and the fabric switch. In theillustrated embodiment, the interface between each of compute nodes 1202₁₋₄ and the FPGA 1210 comprises an SPI (System Packet Interface) 4.2interface, while the interface between the FPGA and backplane fabricswitch 1208 comprises a Broadcom HiGig™ interface. It is noted thatthese interfaces are merely exemplary, and that other interface may beemployed depending on the native interfaces of the various bladecomponents.

In addition to local RAM (e.g., RAM 1204 ₁), the compute node associatedwith the OAMP function (depicted in FIG. 12 as Compute Node #1) isprovided with local SRAM 1212 and a non-volatile store (depicted asCompact flash 1214). The non-volatile store is used to store persistentdata used for the OAMP function, such as provisioning information andlogs. In Compute Blades that do not support the OAMP function, eachcompute node is provided with local RAM and a local cache.

In the embodiment illustrated in FIG. 12, compute blade 215 isprovisioned as an OAMP blade. In one configuration (as shown), one ofthe compute nodes is employed for performing OAMP functions (e.g.,compute node 1202 ₁), while the other three compute nodes (e.g., computenodes 1202 ₂₋₄) perform normal compute functions associated with computeblades, as described in further detail below. When a compute blade 215is provisioned as a compute blade, each of compute nodes 1202 ₁₋₄ isavailable for performing the compute functions described herein.

FIG. 13 shows an exemplary architecture 1300 for a traffic blade 210.Architecture 1300 includes a PHY block 1302, an Ethernet MAC block 1304,a network processor unit (NPU) 1306, a host processor 1308, a SERDESinterface 1310, an FPGA 1312, a backplane fabric switch 1314, RAM 1316and 1318 and cache 1319. The traffic blade further includes one or moreI/O ports 1320, which are operatively coupled to PHY block 1320.Depending on the particular use, the number of I/O ports may vary from 1to N ports. For example, under one traffic blade type a 10×1 GigabitEthernet (GigE) port configuration is provided, while for another type a1×10 GigE port configuration is provided. Other port number and speedcombinations may also be employed.

PHY block 1302 and Ethernet MAC block 1304 respectively perform layer 1(Physical) and layer 2 (Data Link) functions, which are well-known inthe art. In general, the PHY and Ethernet MAC functions may beimplemented in hardware via separate components or a single component,or may be implemented in a combination of hardware and software via anembedded processor or the like.

One of the operations performed by a traffic blade is packetidentification/classification. As discussed above, a multi-levelclassification hierarchy scheme is implemented for this purpose.Typically, a first level of classification, such as a 5-Tuple signatureclassification scheme, is performed by the traffic blade's NPU 1306.Additional classification operations in the classification hierarchy maybe required to fully classify a packet (e.g., identify an applicationflow type). In general, these higher-level classification operations maybe performed by the traffic blade's host processor 1308 and/or aprocessor on a compute blade, depending on the particularclassification.

NPU 1306 includes various interfaces for communicating with other boardcomponents. These include an Ethernet MAC interface, a memory controller(not shown) to access RAM 1316, Ethernet and PCI interfaces tocommunicate with host processor 1308, and an XGMII interface. SERDESinterface 1310 provides the interface between XGMII interface signalsand HiGig signals, thus enabling NPU 1306 to communicate with backplanefabric switch 1314. NPU 1306 may also provide additional interfaces tointerface with other components, such as an SRAM (Static Random AccessMemory) interface unit to interface with off-chip SRAM (both not shown).

Similarly, host processor 1308 includes various interfaces forcommunicating with other board components. These include theaforementioned Ethernet and PCI interfaces to communicate with NPU 1306,a memory controller (on-chip or off-chip—not shown) to access RAM 1318,and a pair of SPI 4.2 interfaces. FPGA 1312 is employed to as aninterface between the SPI 4.2 interface signals and the HiGig interfacesignals.

Typically, NPUs are designed for performing particular tasks in a veryefficient manner. These tasks include packet forwarding and packetclassification, among other tasks related to packet processing. Tosupport such functionality, NPU 1306 executes corresponding NPU software1322. This software is shown in dashed outline to indicate that thesoftware may be stored (persist) on a given traffic blade (e.g., in aflash device or the like), or may be downloaded from an external (to thetraffic blade) store during initialization operations, as describedbelow. During run-time execution, NPU software 1322 is loaded intointernal SRAM 1323 provided by NPU 1306.

Host processor 1308 is employed for various purposes, includinglower-level (in the hierarchy) packet classification, gathering andcorrelation of flow statistics, and application of traffic profiles.Host processor 1308 may also be employed for other purposes. In general,host processor 1308 will comprise a general-purpose processor or thelike, and may include one or more compute cores (as illustrated, in oneembodiment a two-core processor is used). As with NPU 1306, thefunctionality performed by host processor is effected via execution ofcorresponding software (e.g., machine code and or virtual machine bytecode), which is depicted as host software 1324. As before, this softwaremay already reside on a traffic blade, or be loaded during bladeinitialization.

In one embodiment, host processor 1308 is responsible for initializingand configuring NPU 1306. Under one initialization scheme, hostprocessor 1308 performs network booting via the DHCP (or BOOTP)protocol. During the network boot process, an operating system is loadedinto RAM 1318 and is booted. The host processor then configures andinitializes NPU 1306 via the PCI interface. Once initialized, NPU 1306may execute NPU software 1322 on a run-time basis, without the need oruse of an operating system.

The processes explained above are described in terms of computersoftware and hardware. The techniques described may constitutemachine-executable instructions embodied within a machine (e.g.,computer) readable medium, that when executed by a machine will causethe machine to perform the operations described. Additionally, theprocesses may be embodied within hardware, such as an applicationspecific integrated circuit (“ASIC”) or the like.

A machine-accessible medium includes any mechanism that provides (i.e.,stores and/or transmits) information in a form accessible by a machine(e.g., a computer, network device, personal digital assistant,manufacturing tool, any device with a set of one or more processors,etc.). For example, a machine-accessible medium includesrecordable/non-recordable media (e.g., read only memory (ROM), randomaccess memory (RAM), magnetic disk storage media, optical storage media,flash memory devices, etc.), as well as electrical, optical, acousticalor other forms of propagated signals (e.g., carrier waves, infraredsignals, digital signals, etc.).

The above description of illustrated embodiments of the invention,including what is described in the Abstract, is not intended to beexhaustive or to limit the invention to the precise forms disclosed.While specific embodiments of, and examples for, the invention aredescribed herein for illustrative purposes, various modifications arepossible within the scope of the invention, as those skilled in therelevant art will recognize.

These modifications can be made to the invention in light of the abovedetailed description. The terms used in the following claims should notbe construed to limit the invention to the specific embodimentsdisclosed in the specification. Rather, the scope of the invention is tobe determined entirely by the following claims, which are to beconstrued in accordance with established doctrines of claiminterpretation.

1. A network device, comprising: a chassis including an interconnect; a plurality of traffic modules installed in the chassis and coupled to the interconnect; a plurality of compute modules installed in the chassis and coupled to the interconnect; and software components distributed across the traffic and compute modules, the software components to execute on processing elements of the traffic and compute modules to perform operations including: execute a management layer on at least one of the compute modules; execute an interface layer on the one of the compute modules; and communicate data between the interface layer and the management layer via invoking a converter to convert the data from a first format used in the interface layer to a serializable object in the management layer.
 2. The network device of claim 1, further comprising a provisioning database communicatively linked to the management layer, wherein the software components include further components to perform operations including: invoking a write method of the serializable object; converting field values of the serializable object into a flat contiguous memory structure with a database converter; and storing the flat contiguous memory structures as a record in the provisioning database.
 3. The network device of claim 2, wherein the software components include further components to perform operations including: publishing a management layer application programming interface (“MLAPI”) into the interface layer; invoking a get command published into the interface layer by the MLAPI; and retrieving the data from the provisioning database.
 4. The network device of claim 1, wherein the software components include further components to perform operations including: executing a runtime layer across the traffic and compute modules; and communicating the data in the serializable object in the management layer to a fixed length memory structure in the runtime layer by invoking a method of the serializable object.
 5. The network device of claim 4, further comprising a runtime database communicatively linked to the runtime layer, wherein the software components include further components to perform operations including: storing the fixed length memory structure into the runtime database.
 6. A method executed on a network device having a plurality of traffic modules interconnected with a plurality of compute modules, the method comprising: executing a management layer on at least one of the compute modules; executing an interface layer on the one of the compute modules; and communicating data between the interface layer and the management layer via invoking a converter to convert the data from a first format used in the interface layer to a serializable object in the management layer.
 7. The method of claim 6, further comprising: executing a provisioning database communicatively linked to the management layer; invoking a write method of the serializable object; converting field values of the serializable object into a flat contiguous memory structure with a database converter; and storing the flat contiguous memory structures as a record in the provisioning database.
 8. The method of claim 7, further comprising: publishing a management layer application programming interface (“MLAPI”) into the interface layer; invoking a get command published into the interface layer by the MLAPI; and retrieving the data from the provisioning database.
 9. The method of claim 6, further comprising: executing a runtime layer across the traffic and compute modules; and communicating the data in the serializable object in the management layer to a fixed length memory structure in the runtime layer by invoking a method of the serializable object.
 10. The method of claim 9, further comprising: executing a runtime database communicatively linked to the runtime layer; and storing the fixed length memory structure into the runtime database.
 11. A computer-readable storage media that provide instructions that, if executed by a network device having a plurality of traffic modules interconnected with a plurality of compute modules, will cause the network node to perform operations comprising: executing a management layer on at least one of the compute modules; executing an interface layer on the one of the compute modules; and communicating data between the interface layer and the management layer via invoking a converter to convert the data from a first format used in the interface layer to a serializable object in the management layer.
 12. The computer-readable storage media of claim 11, further providing instructions that, if executed by the network node, will cause the network node to perform further operations, comprising: executing a provisioning database communicatively linked to the management layer; invoking a write method of the serializable object; converting field values of the serializable object into a flat contiguous memory structure with a database converter; and storing the flat contiguous memory structures as a record in the provisioning database.
 13. The computer-readable storage media of claim 12, further providing instructions that, if executed by the network node, will cause the network node to perform further operations, comprising: publishing a management layer application programming interface (“MLAPI”) into the interface layer; invoking a get command published into the interface layer by the MLAPI; and retrieving the data from the provisioning database.
 14. The computer-readable storage media of claim 11, further providing instructions that, if executed by the network node, will cause the network node to perform further operations, comprising, further comprising: executing a runtime layer across the traffic and compute modules; and communicating the data in the serializable object in the management layer to a fixed length memory structure in the runtime layer by invoking a method of the serializable object.
 15. The computer-readable storage media of claim 14, further providing instructions that, if executed by the network node, will cause the network node to perform further operations, comprising: executing a runtime database communicatively linked to the runtime layer; and storing the fixed length memory structure into the runtime database. 